Florin,

On May 8, 2010, at 12:12 MDT, Balus, Florin Stelian (Florin) wrote:
> Shane,
>  
> I am fine to stick to the process and give people more time considering it is a weekend and they need to try to follow the exchanges on the list. Personally I think there were no arguments that were not discussed at length for the last couple of years in IETF L2VPN sessions or in Ali's expired draft on native CMAC flushing for PBB-VPLS.
>  
> I will also be happy to discuss new feedback from new voices or from whoever spoke before on the list.
>  
> Can you clarify though what do you expect to happen from people that already voted one way or another and did not change their opinion? Do you want another round of votes?

I do not want to start "another round of votes", since people should have been familiar with the drafts, use cases and related technologies when their cast their opinion on the list.  That said, if as a result of the discussion over the past few days a WG member has had a change of opinion, then they are free to do so on the list.  It would also be useful if, at the same time, they could share the reasons why they were changing their opinion in order to ensure there aren't any misunderstandings.

Thanks,

-shane
(co-chair L2VPN WG)


> Thanks,
> Florin
>  
> > -----Original Message-----
> > From: Shane Amante [mailto:shane@castlepoint.net]
> > Sent: Friday, May 07, 2010 6:47 PM
> > To: Ali Sajassi
> > Cc: Balus, Florin Stelian (Florin); l2vpn@ietf.org; giles.heron@bt.com
> > Subject: Re: Merge MAC Withdraw Drafts?
> >
> > Ali, Florin, Pranjal, et. al,
> >
> > On May 7, 2010, at 18:59 MDT, Ali Sajassi (sajassi) wrote:
> > > Shane, Giles:
> > >
> > > I think, we have spent enough time and energy to discuss this subject
> > > and I hope this discussion has been informative to our SP colleagues
> > and
> > > the pros/cons of these two approaches are now clear since they are
> > the
> > > real owner of these solutions. If after these healthy discussions,
> > there
> > > are still some SPs/operators who want to go with LDP-based MAC
> > withdraw
> > > for C-MACs in PBB-VPLS, then I would like to hear from them since
> > they
> > > should have the final say.
> >
> > I agree that this particular dialogue has played itself out.  And, it
> > does appear like you're at the point of "agreeing to disagree", which
> > is perfectly fine.  I think all parties have had the opportunity to
> > present their case in the open light of the mailing list and now it's
> > up the individual members of the WG (who represent both operators _and_
> > equipment vendors, as should be evident by all the e-mails from people
> > who've weighed in on this particular thread) to take all of the points
> > raised into consideration and decide for themselves what should be
> > done.  This is why the call on whether or not to merge these two drafts
> > will remain open for another week until Friday, May 14th, as was
> > pointed out in the original e-mail that we sent out on this subject.
> > Once the call closes, we will attempt to determine the consensus of the
> > WG with respect to these two drafts, as we would normally do.
> >
> > In the mean time, we would appreciate if everyone would continue to
> > maintain a professional tone in their e-mails, (as everyone has done),
> > as well as avoid a point-by-point or mail-by-mail back-and-forth,
> > particularly on areas that have been previously covered.  IOW, making
> > the same point over-and-over is not very constructive, particularly if
> > other WG members want to ask questions or cast their opinion.  Of
> > course, if there are incorrect technical facts that are brought up in
> > subsequent discussions, then those should be duly corrected.
> >
> > Thanks,
> >
> > -shane
> > (co-chair L2VPN WG)
> >
> >
> >
> >
> >
> > > Again, here is the summary for pros/cons of each approach based on my
> > > previous email:
> > >
> > > LDP-based:
> > > -------------
> > > Pros:
> > > -   Simple to implement, no certification required, no OSS
> > > modification
> > > -   Works for E2E MPLS only
> > > Cons:
> > > -   Slower to converge (relative to Ethernet mechanism)
> > > -   Creates interop issues and will require additional interop
> > > solutions
> > > -   Requires implementing, testing, and operating such interop
> > > solutions
> > >
> > > Native Ethernet-based:
> > > Pros:
> > > -   Simple to implement, no certification required, no OSS
> > > modification
> > > -   Works for E2E MPLS
> > > -   Faster to converge
> > > -   No interop issue
> > > -   No additional interop solution development, testing, and
> > > operating
> > > Cons:
> > > -   None ( based on this long email thread, no one has pointed a
> > > single con regarding this)
> > >
> > >
> > > Florin, a few comments inline to your response
> > >
> > > - Ali
> > >
> > >> -----Original Message-----
> > >> From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> > >> lucent.com]
> > >> Sent: Friday, May 07, 2010 10:30 AM
> > >> To: Ali Sajassi (sajassi); Shane Amante; l2vpn@ietf.org; Giles Heron
> > >> (giles.heron@bt.com)
> > >> Subject: RE: Merge MAC Withdraw Drafts?
> > >>
> > >> Shane, Giles,
> > >>
> > >> We have been rambling on this draft that requires only a new LDP TLV
> > >> for way too long and I think we did our best to answers Ali's
> > points.
> > >> With the reply below I think we are at a point where we need to
> > >> conclude it is ok to agree to disagree - this is supposed to be my
> > >> night job! I wonder what will happen if we have to debate a 20 page
> > >> draft! :)
> > >>
> > >> Ali,
> > >>
> > >> I will summarize the point that is left on scalability to make some
> > >> steps towards the closure:
> > >> - you are admitting below there was "a perfect reason" to use LDP
> > hop-
> > >> by-hop for MS-PW status and LDP MAC Flush.
> > >
> > > For B-MACs !! and there is perfect reason for not doing it for C-MACs
> > > :-)
> > >
> > >> - you do not have any real example to demonstrate the LDP hop-by-hop
> > >> procedure is broken - I prompted you to bring up any bad experience
> > >> with implementing and deploying HVPLS, MS-PWs and I did not see any
> > >> reply.
> > >
> > > I never said it is broken or I have a bad experience with it. I have
> > > been saying that is a bad solution for C-MACs because of the above
> > > reasons (refer to the summary).
> > >
> > >> - I asked you to highlight also any initiative targeted at fixing
> > > these
> > >> mechanisms in L2VPN or PWE3 and you did not reply with anything
> > > either.
> > >
> > > Again, my issue is not with B-MAC flushing. As I said numerous times,
> > > you can extend the B-MAC flush for C-MAC addresses but you will
> > create
> > > tons of interop issues down the road and if every SDO does the same
> > > thing we will have a nightmare. You have conveniently sidestepping
> > these
> > > interop issues and saying that they should be taken care later.
> > >
> > >> - So we should conclude that this procedure is working just fine in
> > >> real life deployments.
> > >> - We are proposing an enhanced use of this LDP hop-by-hop procedure
> > >> where compared with the above mechanism the PE-rs do not perform any
> > >> data plane function. Worthwhile to note for completion that VPLS
> > Mesh
> > >> does not use LDP hop-by-hop anyhow.
> > >>
> > >> So in conclusion I think we need to close this thread too: there is
> > no
> > >> scaling problem and the proposed mechanism will work even better
> > than
> > >> in the MS-PW and HVPLS cases to address customer requirements for
> > one
> > >> toolset in an MPLS E2E scenario.
> > >>
> > >> The rest is just academic discussion. I will try to address in-line
> > >> anything that resembles some scalability discussion just because I
> > > like
> > >> Ali. :)
> > >
> > > And I like you - no hard feeling :-)
> > >
> > > -Ali
> > >
> > >> The rest we can continue as a discussion in IEEE.
> > >>
> > >> Florin
> > >
>  
>